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Abstract 


Distribution of this memo is unlimited. 


The content of many communication services depends on the context, 


such as the user’s location. We describe a ’service’ 


URN that allows 


well-known context-dependent services that can be resolved ina 


distributed manner to be identified. 


Examples include emergency 


services, directory assistance, and call-before-you-dig hot lines. 
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Introduction 


In existing telecommunications systems, there are many well-known 
communication and information services that are offered by loosely 
coordinated entities across a large geographic region, with well- 
known identifiers. Some of the services are operated by governments 
or regulated monopolies, others by competing commercial enterprises. 
Examples include emergency services (reached by dialing 9-1-1 in 
North America, 1-1-2 in Europe), community services and volunteer 
opportunities (2-1-1 in some regions of the United States), telephone 
directory and repair services (4-1-1 and 6-1-1 in the United States 
and Canada), government information services (3-1-1 in some cities in 
the United States), lawyer referral services (1-800-LAWYER), car 
roadside assistance (automobile clubs), and pizza delivery services. 
Unfortunately, almost all of them are limited in scope to a single 
country or possibly a group of countries, such as those belonging to 
the North American Numbering Plan or the European Union. The same 
identifiers are often used for other purposes outside that region, 
making access to such services difficult when users travel or use 
devices produced outside their home country. 


These services are characterized by long-term stability of user- 
visible identifiers, decentralized administration of the underlying 
service, and a well-defined resolution or mapping mechanism. For 
example, there is no national coordination or call center for "9-1-1" 
in the United States; rather, various local government organizations 
cooperate to provide this service based on jurisdictions. 


In this document, we propose a URN namespace that, together with 
resolution protocols beyond the scope of this document, allows us to 
define such global, well-known services, while distributing the 
actual implementation across a large number of service-providing 
entities. There are many ways to divide provision of such services, 
such as dividing responsibility by geographic region or by the 
service provider a user chooses. In addition, users can choose 
different mapping service providers that in turn manage how 
geographic locations are mapped to service providers. 


Availability of such service identifiers allows end systems to convey 
information about the desired service to other network entities. For 
example, an IP phone could have a special set of short cuts, address 
book entries, or buttons that invoke emergency services. When such a 
service identifier is put into the outgoing Session Initiation 
Protocol (SIP) [RFC3261] message, it allows SIP proxies to 
unambiguously take actions, as it would not be practical to configure 
them with dial strings and emergency numbers used throughout the 
world. Hence, such service identifiers make it possible to delegate 
routing decisions to third parties and to mark certain requests as 
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having special characteristics while preventing these characteristics 
from being accidentally invoked. 


This URN identifies services independent of the particular protocol 
that is used to request or deliver the service. The URN may appear 
in protocols that allow general URIs, such as the SIP [RFC3261] 
request URIs, web pages, or mapping protocols. 


The service URN is a protocol element and is generally not expected 
to be visible to humans. For example, it is expected that callers 
will still dial the emergency number ’9-1-1’ in the United States to 
reach emergency services. In some other cases, speed dial buttons 
might identify the service, as is common practice on hotel phones 
today. (Speed dial buttons for summoning emergency help are 
considered inappropriate by most emergency services professionals, at 
least for mobile devices, as they are too prone to being triggered 
accidentally.) 


The translation of service dial strings or service numbers to service 
URNs in the end host is beyond the scope of this document. These 
translations likely depend on the location of the caller and may be 
many-to-one, i.e., several service numbers may map to one service 
URN. For example, a phone for a traveler could recognize the 
emergency service number for both the traveler’s home location and 
the traveler’s visited location, mapping both to the same universal 
service URN, urn:service:sos. 


Since service URNs are not routable, a SIP proxy or user agent has to 
translate the service URN into a routable URI for a location- 
appropriate service provider, such as a SIP URL. A Location-to- 
Service Translation Protocol (LoST) [LOST] is expected to be used as 
a resolution system for mapping service URNs to URLs based on 
geographic location. In the future, there may be several such 
protocols, possibly different ones for different services. 


Services are described by top-level service type, and may contain a 
hierarchy of sub-services that further describe the service, as 
outlined in Section 3. 


We discuss alternative approaches for creating service identifiers, 
and why they are unsatisfactory, in Appendix A. 
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Terminology 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in RFC 2119 
[RFC2119]. 


Terminology specific to emergency services is defined in [RFC5012]. 
Registration Template 


Below, we include the registration template for the URN scheme 
according to RFC 3406 [RFC3406]. 


Namespace ID: service 
Registration Information: 
Registration version: 1 
Registration date: 2006-04-02 
Declared registrant of the namespace: 
Registering organization: IETF 
Designated contact: Henning Schulzrinne 
Designated contact email: hgs@cs.columbia.edu 


Declaration of syntactic structure: The URN consists of a 
hierarchical service identifier, with a sequence of labels 
separated by periods. The left-most label is the most significant 
one and is called /’/top-level service’, while names to the right 
are called ’sub-services’. The set of allowable characters is the 
same as that for domain names [RFC1123] and a subset of the labels 
allowed in [RFC3958]. Labels are case-insensitive, but MUST be 
specified in all lower-case. For any given service URN, service- 
identifiers can be removed right-to-left; the resulting URN is 
still valid, referring to a more generic service. In other words, 
if a service ’x.y.z’ exists, the URNs ’x’ and ’x.y’ are also valid 
service URNs. The ABNF [RFC4234] is shown below. 
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service-URN 


"URN: service: 


service 


service = top-level *("." sub-service) 
top-level = let-dig [ *25let-dig-hyp let-dig ] 
sub-service = let-dig [ *let-dig-hyp let-dig ] 
let-dig-hyp = let-dig / "-" 
let-dig = ALPHA / DIGIT 
ALPHA = $x41-5A / %x61-7A ; A-Z / a-z 
DIGIT = $x30-39 ; 0-9 

Relevant ancillary documentation: None 


Community considerations: 


to a large cross-section of 
technical and non-technical 
particularly for mobile and 


service URN is believed to be relevant 
Internet users, including both 

users, on a variety of devices, but 
nomadic users. The service URN will 


The 


allow Internet users needing services to identify the service by 


kind, 


particular service in the user’s current context, 
user’s current location. 


without having to determine manually who provides the 


e.g., at the 


For example, travelers will be able to 


use their mobile devices to request emergency services without 
having to know the emergency dial string of the visited country. 
The assignment of identifiers is described in the IANA 


Considerations 


of different entities 


Namespace considerations: 


(Section 4). 
particular resolution mechanism, 


The service URN does not prescribe a 
but it is assumed that a number 
could operate and offer such mechanisms. 


There do not appear to be other URN 


namespaces that serve 


widely-available communication and information services. 
most other currently registered URN namespaces, 
does not identify documents and protocol objects 


[RFC3187], 
equipment 
[RFC3966] 
identifying services 


[RFC4179], 
[RFC4152], 


people, 
identify telephone numbers, 
(such as 911 or 112) 


the same need of uniquely identifying 

Unlike 

the service URN 
(e.g., [RFC3044], 

and [RFC4195]), types of telecommunications 

or organizations [RFC3043]. tel URIs 

but numbers commonly 

are specific toa 


particular region or country. 


Identifier uniqueness considerations: 
specified in the service registration 
Resolution of the URN, 
will return a particular instance of the service, 


logical service, 
Considerations (Section 4)). 
successful, 


A service URN identifies a 
(see IANA 
if 

and 


this instance may be different even for two users making the same 


request in the same place at the same time; 


identified by the URN, however, 


URNs MUST be unique for each unique service; 


the logical service 
is persistent and unique. Service 
this is guaranteed 


through the registration of each service within this namespace, 


described in Section 4. 
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Identifier persistence considerations: The ’service’ URN for the 
same service is expected to be persistent, although there 
naturally cannot be a guarantee that a particular service will 
continue to be available globally or at all times. 


Process of identifier assignment: The process of identifier 
assignment is described in the IANA Considerations (Section 4). 


Process for identifier resolution: There is no single global 
resolution service for ’service’ URNs. However, each top-level 
service can provide a set of mapping protocols to be used with 
‘service’ URNs of that service. 


Rules for lexical equivalence: ’service’ identifiers are compared 
according to case-insensitive string equality. 


Conformance with URN syntax: The BNF in the ’Declaration of 
syntactic structure’ above constrains the syntax for this URN 
scheme. 


Validation mechanism: Validation determines whether a given string 
is currently a validly-assigned URN [RFC3406]. Due to the 
distributed nature of the mapping mechanism, and since not all 
services are available everywhere and not all mapping servers may 
be configured with all current service registrations, validation 
in this sense is not possible. Also, the discovery mechanism for 
the mapping mechanism may not be configured with all current top- 
level services. 


Scope: The scope for this URN is public and global. 
4. IANA Considerations 


This section registers a new URN scheme with the registration 
template provided in Section 3. 


Below, Section 4.1 details how to register new service-identifying 
labels. Descriptions of sub-services for the first two services to 
be registered, sos and counseling, are given in Section 4.2 and 
Section 4.3, respectively. Finally, Section 4.4 contains the initial 
registration table. 


4.1. New Service-Identifying Labels 
Services and sub-services are identified by labels managed by IANA, 
according to the processes outlined in [RFC2434] in a new registry 


called "Service URN Labels". Thus, creating a new service requires 
IANA action. The policy for adding top-level service labels is 
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ROAR 


‘Standards Action’. (This document defines the top-level services 
sos’ and ’counseling’.) The policy for assigning labels to sub- 
services may differ for each top-level service designation and MUST 
be defined by the document describing the top-level service. 


Entries in the registration table have the following format: 


Service Reference Description 
foo RFCxyz Brief description of the ’foo’ top-level service 
foo.bar RFCabc Description of the ’foo.bar’ service 


To allow use within the constraints of S-NAPTR [RFC3958], all top- 
level service names MUST NOT exceed 27 characters. 


Sub-Services for the ’sos’ Service 


This section defines the first service registration within the IANA 
registry defined in Section 4.1, using the top-level service label 
‘sos’. 


The ’sos’ service type describes emergency services requiring an 
immediate response, typically offered by various branches of the 
government or other public institutions. Additional sub-services can 
be added after expert review and must be of general public interest 
and have a similar emergency nature. The expert is designated by the 
ECRIT working group, its successor, or, in their absence, the IESG. 
The expert review should only approve emergency services that are 
offered widely and in different countries, with approximately the 
same caller expectation in terms of services rendered. The ’sos’ 
service is not meant to invoke general government, public 
information, counseling, or social services. 


urn:service:sos The generic ’sos’ service reaches a public safety 
answering point (PSAP), which in turn dispatches aid appropriate 
to the emergency. It encompasses all of the services listed 
below. 


urn:service:sos.ambulance This service identifier reaches an 
ambulance service that provides emergency medical assistance and 
transportation. 


urn:service:sos.animal-control Animal control typically enforces 
laws and ordinances pertaining to animal control and management, 
investigates cases of animal abuse, educates the community in 
responsible pet ownership and wildlife care, and provides for the 
housing and care of homeless animals, among other animal-related 
services. 
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urn:service:sos.fire The ’fire’ service identifier summons the fire 
service, also known as the fire brigade or fire department. 


urn:service:sos.gas The ’gas’ service allows the reporting of 
natural gas (and other flammable gas) leaks or other natural gas 
emergencies. 


urn:service:sos.marine The ’/marine’ service refers to maritime 
search and rescue services such as those offered by the coast 
guard, lifeboat, or surf lifesavers. 


urn:service:sos.mountain The ’mountain’ service refers to mountain 
rescue services (i.e., search and rescue activities that occur in 
a mountainous environment), although the term is sometimes also 
used to apply to search and rescue in other wilderness 
environments. 


urn:service:sos.physician The ’physician’ emergency service connects 
the caller to a physician referral service. 


urn:service:sos.poison The ’poison’ service refers to special 
information centers set up to inform citizens about how to respond 
to potential poisoning. These poison control centers maintain a 
database of poisons and appropriate emergency treatment. 


urn:service:sos.police The ’police’ service refers to the police 
department or other law enforcement authorities. 


4.3. Sub-Services for the ’counseling’ Service 


The ’counseling’ service type describes services where callers can 
receive advice and support, often anonymous, but not requiring an 
emergency response. (Naturally, such services may transfer callers 
to an emergency service or summon such services if the situation 
warrants.) Additional sub-services can be added after expert review 
and should be of general public interest. The expert is chosen in 
the same manner as described for the ’sos’ service. The expert 
review should take into account whether these services are offered 
widely and in different countries, with approximately the same caller 
expectation in terms of services rendered. 


urn:service:counseling The generic /’/counseling’ service reaches a 


call center that transfers the caller based on his or her specific 
needs. 
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urn:service:counseling.children The ’children’ service refers to 
counseling and support services that are specifically tailored to 
the needs of children. Such services may, for example, provide 
advice to run-aways or victims of child abuse. 


urn:service:counseling.mental-health The /’/mental-health’ service 
refers to the "diagnostic, treatment, and preventive care that 
helps improve how persons with mental illness feel both physically 
and emotionally as well as how they interact with other persons". 
(U.S. Department of Health and Human Services) 


urn:service:counseling.suicide The ’suicide’ service refers to the 
suicide prevention hotline. 


4.4. Initial IANA Registration 


The following table contains the initial IANA registration for 
emergency and counseling services. 


Service Reference Description 
counseling RFC 5031 Counseling services 
counseling.children RFC 5031 Counseling for children 
counseling.mental-health RFC 5031 Mental health counseling 
counseling.suicide RFC 5031 Suicide prevention hotline 
sos RFC 5031 Emergency services 
sos.ambulance RFC 5031 Ambulance service 
sos.animal-control RFC 5031 Animal control 
sos.fire RFC 5031 Fire service 
sos.gas RFC 5031 Gas leaks and gas emergencies 
sos.marine RFC 5031 Maritime search and rescue 
sos.mountain RFC 5031 Mountain rescue 
sos.physician RFC 5031 Physician referral service 
sos.poison RFC 5031 Poison control center 
sos.police RFC 5031 Police, law enforcement 

5. Internationalization Considerations 


The service labels are protocol elements [RFC3536] and are not 
normally seen by users. Thus, the character set for these elements 
is restricted, as described in Section 3. 
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6. Security Considerations 


As an identifier, the service URN does not appear to raise any 
particular security issues. The services described by the URN are 
meant to be well-known, even if the particular service instance is 
access-controlled, so privacy considerations do not apply to the URN. 


There are likely no specific privacy issues when including a service 
URN on a web page, for example. On the other hand, ferrying the URN 
in a signaling protocol can give attackers information on the kind of 
service desired by the caller. For example, this makes it easier for 
the attacker to automatically find all calls for emergency services 
or directory assistance. Appropriate, protocol-specific security 
mechanisms need to be implemented for protocols carrying service 


URNs. The mapping protocol needs to address a number of threats, as 
detailed in [RFC5069]. That document also discusses the security 
considerations related to the use of the service URN for emergency 
services. 
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Appendix A. Alternative Approaches Considered 


The discussions of ways to identify emergency calls has yielded a 
number of proposals. Since these are occasionally brought up during 
discussions, we briefly summarize why this document chose not to 
pursue these solutions. 


tel:NNN;context=+C This approach uses tel URIs [RFC3966]. Here, NNN 
is the national emergency number, where the country is identified 
by the context C. This approach is easy for user agents to 


implement, but hard for proxies and other SIP elements to 
recognize, as it would have to know about all number-context 
combinations in the world and track occasional changes. In 
addition, many of these numbers are being used for other services. 
For example, the emergency number in Paraguay (00) is also used to 
call the international operator in the United States. As another 
example, a number of countries, such as Italy, use 118 as an 
emergency number, but it also connects to directory assistance in 
Finland. 


tel:sos This solution avoids name conflicts, but requires extending 
the "tel" URI "tel" [RFC3966]. It also only works if every 
outbound proxy knows how to route requests to a proxy that can 
reach emergency services since tel URIs do not identify the 
destination server. 


sip:sos@domain Earlier work had defined a special user identifier, 
sos, within the caller’s home domain in a SIP URI, for example, 
sip:sos@example.com. Such a user identifier follows the 
convention of RFC 2142 [RFC2142] and the "postmaster" convention 
documented in RFC 2822 [RFC2822]. This approach had the advantage 
that dial plans in existing user agents could probably be 
converted to generate such a URI and that only the home proxy for 
the domain has to understand the user naming convention. However, 
it overloads the user part of the URI with specific semantics 
rather than being opaque, makes routing by the outbound proxy a 
special case that does not conform to normal SIP request-URI 
handling rules and is SIP-specific. The mechanism also does not 
extend readily to other services. 


SIP URI user parameter: One could create a special URI, such as 
"aor-domain;user=sos". This avoids the name conflict problem, but 
requires mechanism-aware user agents that are capable of emitting 
this special URI. Also, the ’user’ parameter is meant to describe 
the format of the user part of the SIP URI, which this usage does 
not do. Adding other parameters still leaves unclear what, if 
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any, conventions should be used for the user and domain part of 
the URL. Neither solution is likely to be backward-compatible 
with existing clients. 


Special domain: A special domain, such as "sip:fire@sos.int" could 
be used to identify emergency calls. This has similar properties 
as the "tel:sos" URI, except that it is indeed a valid URI. To 
make this usable, the special domain would have to be operational 
and point to an appropriate emergency services proxy. Having a 
Single, if logical, emergency services proxy for the whole world 
seems to have undesirable scaling and administrative properties. 
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